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REMARKS 

Reexamination and reconsideration of this application is requested. Claims 1,3, 
6, 8, 13, and 17 have been amended. After this Response, Claims 1-20 remain pending 
in this application. Applicant believes that Clams 1-20 recite in allowable form. 

Correction of Cross-Reference To Related Applications 

Applicant has corrected a minor typo in the identification of one of the related 
applications as was previously amended in the immediately previous Response to Office. 
No new matter was added by the present correction. 

Rejection Of Claim To Priority 

(1) The Examiner stated on page 2 of the present Office Action that the "Applicant ' 
has not complied with one or more conditions for receiving the benefit of an earlier filing 
date". The Examiner further states that because 'the applications are not copending, the 
benefit claim to the prior-filed nonpro visional application is improper". 

The Applicant respectfully points the Examiner to pages 9 and 10 of the previous 
Response dated November 14, 2005, which include sufficient evidence of copendency 
between the present application and U.S. Patent Nos. 6,415,312, 6,502,140, and 
6,625,773. In particular, pages 9 and 10 of the previous Response explicitly show that 
the above referenced Patents were filed on January 29, 1999, January 29, 1999, and June 
9, 1999, respectively, and issued as U.S. Patents on July 2, 2002, December 31, 2002, and 
September 23, 2003, respectively. Therefore, because the present Application was filed 
on October 25, 2000, the present Application and the applications corresponding to U.S. 
Patent Nos. 6,415,312, 6,502,140, and 6,625,773 were co-pending as required by C.F.R. 
§ 1 .78. Furthermore, the present Application and U.S. Patent Nos. 6,41 5,312, 6,502,140, 
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and 6,625,773 all name a common inventor. The Applicant has included the relevant 
sections of C.F.R. § L78 below for the Examiner's reference. 

a nonprovisional application . . . may claim an invention disclosed 
in one or more prior-filed copending nonprovisional applications... In 
order for an application to claim the benefit of a prior-filed copending 
nonprovisional application or international application designating the 
United States of America, each prior-filed application must name as an 
inventor at least one inventor named in the later-filed application and 
disclose the named inventor's invention claimed in at least one claim of 
the later-filed application in the manner provided by the first paragraph of 
35 U.S.C. 112. ...[A]ny nonprovisional application ...claiming the benefit 
of one or more prior-filed copending nonprovisional applications... must 
contain or be amended to contain a reference to each such prior-filed 
application, identifying it by application number (consisting of the series 
code and serial number) ...indicating the relationship of the 
applications,.. This reference must be submitted during the pendency of 
the later-filed application. If the later-filed application is an application 
filed under 35 U.S.C. 1 1 1 (a), this reference must also be submitted within 
the later of four months from the actual filing date of the later-filed 
application or sixteen months from the filing date of the prior-filed 
application... The time periods in this paragraph do not apply if the later- 
filed application is... An application filed under 35 U.S.C. Ill (a) before 
November 29, 2000..." 

Applications corresponding to U.S. Patent Nos. 6,415,312, 6,502,140, and 6,625,773 
were co-pending at the time of filling the present application. Additionally, the present 
application was filed on October 25, 2000, which is "before November 29, 2000". 
Therefore, the requirement of submitting the reference to the co-pending applications 
"within the later of four months from the actual filing date of the later-filed application or 
sixteen months from the filing date of the prior-filed application" does not apply. 
Accordingly, the requirement of co-pendency of the present application with the prior 
three applications has been met. 

The Examiner also rejected the Applicant's claim to priority U.S. Patent Nos. 
6,415,312, 6,502,140, and 6,625,773 stating that the "disclosure of the prior-filed 
application, Application No. 09/240,546 (now, issued as U.S. Patent No. 6,415,312), 
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application No. 09/240,549 (now, issued as U.S. Pat. No. 6,502,140) and application No. 
09/329,101 (now, issued as 6,625,773), fail to provide adequate support or enablement in 
the manner provided by the first paragraph of 35 U.S.C. 1 12 for one or more claims of 
this application. 



Claim 1, as amended, now recites: 

A method for distributing electronic mail efficiently across a network of 
information processing units and intermediate nodes, the method on an 
information processing unit comprising the steps of: 

receiving a mail message that is created and sent by a user, the user 
associating the mail message with a plurality of individual destinations; 
and 

. sending a single copy of the mail message, in a multicast packet 
and using a reliable multicast technique, across the network via at least 
one intermediate node to the plurality of individual destinations, the 
plurality of individual destinations corresponding to a plurality of 
individual destination network addresses, wherein the multicast packet 
includes a packet header comprising the plurality of individual destination 
network addresses, wherein at least one of the plurality of individual 
destination network addresses is a unicast address, and wherein the mail 
message is destined for reception at the individual destination 
corresponding to the unicast address as an ordinary unicast packet. 

With respect to Claim 1 and similarly for Claim 6, the Applicant has provided the 
following claim chart, which identifies the adequate support in U.S. Patent Nos. 
6,415,312, 6,502,140, and 6,625,773 for each claim element of Claim 1. 



receiving a mail message that is created and 
sent by a user, 



U.S. Patent No. 6,415,312 at col. 6, lines 
31-44, U.S. Patent No. 6,502,140 col. 2, 
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lines 66-68 to col. 3, lines 1-26. 


the user associating the mail message with 
a plurality of individual destinations 


U.S. Patent No. 6,625,773 col. 2, lines 35- 
36; col. 3, lines 37-41; col. 4, lines 2-16 


sending a single copy of the mail message, 
in a multicast packet 


U.S. Patent No. 6,625,773 col. 4, lines 36- 
40; col. 4, lines 2-16; col. 6, lines 41-43; 
U.S. Patent No. 6,415,312 col. 3, line 1-30. 


and using a reliable multicast technique 


U.S Patent No. 6,625,773 col. 6, lines 60- 
67 to col. 7, lines 1-27; U.S. Patent No. 
6,415,312 Abstract; col. 6, lines 54-67 to 
col. 7, lines 1-47. 


across the network via at least one 
intermediate node to the plurality of 
individual destinations 


U.S. Patent No. 6,625,773 FIG. 1, col. 3, 
lines 18-24; col. 3, lines 34-37 


the plurality of individual destinations 
corresponding to a plurality of individual 
destination network addresses, 


U.S. Patent No. 6,415,312 col. 3, lines 48- 
51; U.S. Patent No. 6,502,140 col. 3, lines 
47-50 


wherein the multicast packet includes a 
packet header comprising the plurality of 
individual destination network addresses, 


U.S. Patent No. 6,415,3 12 col. 2, lines 66- 
67 to col. 3, lines 1-52; U.S. Patent No. 
6,502,140 col. 2, lines 65-67 to col. 3, lines 
1- 50; U.S. Patent No. 6,625,773 col. 4, 
lines 2-16 


wherein at least one of the plurality of 
individual destination network addresses is 
a unicast address, 


U.S. Patent No. 6,415,312 col. 3, lines 48- 
49; U.S. Patent No. 6,502,140 col. 3, lines 
47-48 


and wherein the mail message is destined 
for reception at the individual destination 
corresponding to the unicast address as an 
ordinary unicast packet 


U.S. Patent No. 6,415,312 col. 3, lines 48- 
49; U.S. Patent No. 6,502,140 col. 3, lines 
47-48; col. 2, lines 23-25; col. 6, lines 7- 
26; U.S. Patent No. 6,625,773 col. 4, lines 
47-60. 



The claim element "receiving a mail message that is created and sent by a user," is 

supported in: 

US. Patent No. 6,415,312 at col. 6, lines 31-44, which states 
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"The multicast scheme discussed above provides for an "unreliable" multicast. That is, 
there's no provision for dealing with packets that are lost due to network congestion or 
because they were garbled during transmission due to line-noise, for example. This kind 
of "unreliable" transmission is useful in many applications in which the "timeliness" of 
packet delivery is more important than getting an "old" packet that was lost re- 
transmitted. IP telephony and video conferencing are applications in which the timeliness 
of packet delivery is more important than retransmitting an old packet that got lost. In 
other applications, like file transfer and electronic mail, reliability is more important than 
timeliness. A reliable multicast scheme would also be very useful" 

U.S. Patent No. 6,502,140 col. 2, lines 66-68 to col. 3, lines 1-26, which states 

"When the user of the source node A wishes to send a multicast packet, the data 
processing system at source node A prepares a packet (or set of packets) that includes 
information that intermediate nodes can use to deliver the packet to the desired 
destinations. In the example shown, source node A can send a multicast transmission to 
destination nodes B, C and D by sending a transmission (including a packet or set of 
packets) 11 to an intermediate node Rl that includes appropriate instructions so that: (1) 
node Rl can forward an appropriate packet 13 to node B; and (2) node Rl can forward an 
appropriate packet 15 to R2 that node R2, in turn, can use to forward appropriate packets 
1 7 & 19 on to nodes C and D respectively. 

"The packet 11 that node A sends to node Rl may look like this: IP header: dest=Rl, 
src=A, protocol=encapsulated multicast (i.e. a new protocol type) EP payload: contains an 
encapsulated multicast datagram" 

"Where the encapsulated multicast (EM) datagram might look like this: EM header: one 
byte indicating the header length and a variable number of bytes of "multicast routing 
information". The EM . header can be defined in a number of ways. One possibility can 
include a version number, a header length, a header checksum and then the actual 
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multicast routing information. EM payload: the payload that A is frying to get delivered 
to B, C, and D" 

The claim element "the user associating the mail message with a plurality of 
destinations" is supported in: 

U.S. Patent No. 6,625,773 col. 2, lines 35-36, which states 
"a plurality of addresses for destination nodes in a packet" 
U.S. Patent No. 6,625,773 col. 4, lines 2-16, which states 

"The new packet type, which can be called "small group multicast" packet, is a level 3 
packet which is to say that it is at the same level as IP in the protocol stack. In fact it has 
much the same function as an IP packet, except for the fact that it is addressed to a list of 
destinations as opposed to a single destination. Ignoring some details, the packet that A 
sends to Rl might look like this: Level 2 header: <dest=level 2 address of Rl> <src=level 

2 address of A> <protocol=small group multicast (i.e. a new level 3 packet type). Level 

3 header: <dest=B C D> <src=A> followed by the payload that A wants delivered to B, C 
and D". 

U.S. Patent No. 6,625,773 col. 3, lines 37-41, which states 

"in the example shown, source node A can send a multicast transmission to destination 
nodes B, C and D by sending a transmission (including a packet or set of packets) to an 
intermediate node Rl that includes the desired list of destinations, B, C and D" 

The claim element "sending a single copy of the mail message, in a multicast packet" 

is supported in: 
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U.S. Patent No. 6,625,773 col. 4, lines 36-40, which states 

"So, in the example above, Rl will send a single packet on to R2 with a destination list of 
<B C D> and R2 will send a single packet to R3 with the same destination list. As used 
herein, a next hop can be either an Internet router or the ultimate destination" 

U.S. Patent No. 6,625,773 col. 4, lines 2-16, which states 

"The new packet type, which can be called "small group multicast" packet, is a level 3 
packet which is to say that it is at the same level as IP in the protocol stack. In fact it has 
much the same function as an IP packet, except for the fact that it is addressed to a list of 
destinations as opposed to a single destination. Ignoring some details, the packet that A 
sends to Rl might look like this: Level 2 header: <dest=level 2 address of Rl> <src=level 

2 address of A> <protocol=small group multicast (i.e. a new level 3 packet type). Level 

3 header: <dest=B C D> <src=A> followed by the payload that A wants delivered to B, C 
and D" 

U.S. Patent No. 6,415,312 col. 3, line 1-30, which states 

"node A prepares a packet (or set of packets) that includes information that intermediate 
nodes can use to deliver the packet to the desired destinations. In the example shown, 
source node A can send a multicast transmission to destination nodes B, C and D by 
sending a transmission (including a packet or set of packets) II to an intermediate node 
Rl that includes appropriate instructions so that: (1) node Rl can forward an appropriate 
packet 13 to node B; and (2) node Rl can forward an appropriate packet 15 to R2 that 
node R2, in rum, can use to forward appropriate packets 17 & 19 on to nodes C and D 
respectively' 

"The packet 11 that node A sends to node Rl may look like this: IP header: desr=Rl, 
src=A, protocol=encapsulated multicast (i.e. a new protocol type) IP payload: contains an 
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encapsulated multicast datagram Where the encapsulated multicast (EM) datagram might 
look like this: EM header: one byte indicating the header length and a variable number of 
bytes of "multicast routing mformation , \ The EM header can be defined in a number of 
ways. One possibility can include a version number, a header length, a header checksum 
and then the actual, multicast routing information. EM payload: the payload that A is 
trying to get delivered to B, C, and D The multicast routing information may look like: 
B R2(CD)" 

The claim element "and using a reliable multicast technique" is supported in: 

U.S Patent No. 6,625,773 col. 6, lines 60-67 to col. 7, lines 1-27, which states 

"A reliable multicast scheme can be built by extending the multicast scheme that we have 
been discussing. The scheme would work as follows: an additional header which would 
include a sequence number and a checksum, similar to TCP, would be used to keep track 
of the bytes that have been sent and the bytes that have been successfully received by 
each of the receivers, each of the receivers would send acknowledgments or ACKs to 
inform the sender of the bytes that have been successfully received. The checksum would 
be used to determine if a packet has been received error-free. As in TCP, the ACK 
includes a sequence number to indicate the last byte that has been successfully received. 
(The sequence number could be that of the last byte successfully received or the first byte 
that has not yet been successfully received), as in TCP, the sender concludes that a 
receiver has not successfully received a packet when it does not receive an appropriate 
ACK within a certain period of time. As in TCP, the sender re-transmits a packet that has 
not been successfully received. But unlike TCP, which re-transmits a packet to a single 
receiver, the reliable multicast scheme may need to re-transmit a packet to more than one 
receiver. When the sender needs to re-transmit a packet, it uses a multicast for the re- 
transmission. Since the sender knows the receivers that it needs to re-send to, it can re- 
send to just those receivers. Thus the re-transmissions are optimized and bandwidth is not 
wasted re-transmitting information to nodes that have already successfully received that 
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information. (If the sender needs to re-transmit a packet to a single receiver, the 
"multicast" will, of course, be to a "tree" with a single leaf)" 



U.S. Patent No. 6,415,312 at col. 6, lines 41-43, which states 

"In other applications, like file transfer and electronic mail, reliability is more important 
than timeliness. A reliable multicast scheme would also be very useful" 



U.S. Patent No. 6,415,312 Abstract, which states 

"A system for reliable multicast transmission [multicasting data packets] in a packet- 
based data network" 

U.S Patent No. col. 6, lines 54-67 to col. 7, lines 1-47, which states 

"reliable multicast scheme can be built by extending the multicast scheme for small 
groups as discussed above. This scheme includes all the advantages discussed above and 
it provides reliable multicast transmission. The scheme would work as follows. The EM 
header would include a sequence number and a checksum similar to TCP, which would 
be used to keep track of the bytes that have been sent and the bytes that have been 
successively received by each of the destination nodes. Each of the destinations would 
send acknowledgment signals (e.g, packets), or ACKs, to inform the sender of the bytes 
that they have received successfully and error-free. Two types of acknowledgments may 
be used: positive ACKs indicating an error-free detection at the receiving node and 
negative ACKs indicating that an error was detected in the received packet or packets. 
The checksum could be used to determine if a packet has been received error-free. Other 
error detection or reliability mechanisms can be used (e.g, a cyclic redundancy check)." 

"As in TCP, the ACK includes a sequence number to indicate the last byte that has been 
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successfully received. The sequence number could be that of the last byte successfully 
received or the first byte that has not yet been successfully received." 

"Also as in TCP, the sender could conclude that a receiver has not successfully received a 
packet when it does not receive an appropriate ACK within a certain period of time. As in 
TCP, the sender retransmits a packet that has not been successfully received. But unlike 
TCP, which re-transmits a packet to a single receiver, the reliable multicast scheme may 
need to retransmit a packet to more than one receiver." 

"When the sender needs to retransmit a packet, it uses a multicast tree for the 
retransmission. Since the sender knows the receivers that it needs to resend to and since it 
knows the (unicast) route to each of these receivers (as described above), it can build a 
multicast distribution tree and appropriate multicast routing information for the subset of 
receivers that it needs to re-send to." 

"Thus the retransmissions are optimized. Bandwidth is not wasted retransmitting 
information to nodes that have already successfully received that information. (If the 
sender needs to retransmit a packet to a singe receiver, the "multicast distribution tree" 
will, of course, be a "tree" with a single leaf.)(a receiving node can be an ultimate 
destination node or an intermediate node)." 

"The waiting period for re-transmission can be adjusted such that unnecessary delays are 
not introduced into the system. The waiting period can also be adjusted to the longest 
return time. It is also possible to use a cumulative acknowledgment scheme (as in TCP) 
wherein the source node could use the notion of a transmission window to send a stream 
of packets without waiting for an acknowledgment of each one." 

"As in the multicasting scheme above, most of the work involved is done by the end- 
stations that are participating in the multicast group and the network doesn't need to store 
any state information or run any multicast routing protocols and there is no need for the 
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network operator to negotiate or administer any multicast routing "peering agreements. " 
The reliability scheme discussed herein can be implemented in the EM protocol described 
above or by encapsulating a reliability packet inside the EM payload." 

The claim element "across the network via at least one intermediate node to the 
plurality of destinations' 1 is supported in: 

U.S. Patent No. 6,625,773 FIG. 1, col. 3, lines 18-24, which states- 
"Referring to FIG. 1 there is shown a portion of a data network (or system) 10 
representing an embodiment of the invention. The network 10 includes a plurality of 
nodes each comprising end-stations which can be large host computers or user stations 
like personal computers or telephone handsets, and intermediate nodes which can be 
routers or switches." 

U.S. Patent No. 6,625,773 FIG. 1, col. 3, lines 34-37, which states 

"When the user of the source node A wishes to send a multicast packet, the data 
processing system at source node A prepares a packet (or set of packets) that includes 
information that intermediate nodes can use to deliver the packet to the desired 
destinations" 

The claim element "the plurality of destinations corresponding to a plurality of 
destination network addresses," is supported in: 

U.S. Patent No. 6,415,312 col. 3, lines 48-51; U.S. Patent No. 6,502,140 col. 3, lines 47- 
50, which states . 
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"In one embodiment, the nodes in the list are 4-byte IPv4 unicast addresses, thus the left 
and right parentheses can be encoded in a single byte using values that are not used as the 
first byte of an IPv4 unicast address" 

The claim element "wherein the multicast packet includes a packet header 
comprising the plurality of destination network addresses," is supported in: 

U.S. Patent No. 6,502,140 col. 2, lines 65-67 to col. 3, lines 1- 50; U.S Patent No. 
6,625,773 col. 6, lines 60-67 to col. 7, lines 1-27, which states: 

"When the user of the source node A wishes to send a multicast packet, the data 
processing system at source node A prepares a packet (or set of packets) that includes 
information that intermediate nodes can use to deliver the packet to the desired 
destinations. In the example shown, source node A can send a multicast transmission to 
destination nodes B, C and D by sending a transmission (including a packet or set of 
packets) 11 to an intermediate node Rl that includes appropriate instructions so that: (1) 
node Rl can forward an appropriate packet 13 to node B; and (2) node Rl can forward an 
appropriate packet 15 to R2 that node R2, in turn, can use to forward appropriate packets 
17 & 19 on to nodes C and D respectively." 

"The packet 11 that node A sends to node Rl may look like this: 
IP header: dest=Rl, src=A, protocol=encapsulated multicast (i.e. a new protocol type) 
IP payload: contains an encapsulated multicast datagram Where the encapsulated 
multicast (EM) datagram might look like this: EM header: one byte indicating the header 
length and a variable number of bytes of "multicast routing information". The EM header 
can be defined in a number of ways. One possibility can include a version number, a 
header length, a header checksum and then the actual, multicast routing information." 

"EM payload: the payload that A is trying to get delivered to B, C, and D The multicast 
routing information may look like: .B R2(CD)This multicast routing example means that 
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node Rl should send one packet to node B and one packet to R2 and that the packet to 
node R2 should include instructions that node R2 can use to get the packet to nodes C 
and D." 

"The multicast routing information recursively nests to an arbitrary depth so if node C 
were a router that was supposed to forward packets to nodes E, F, and G, the multicast 
routing information would, look like this: B R2(C(EFG)D) If node F were a router that 
was supposed to forward packets to nodes H & I, the multicast routing information would 
look like this: B R2(C(EF(HI)G)D)A node can be both an intermediate and destination 
node. In the case of a node that is only a destination, the packet transmitted does not 
include instructions for a subsequent node to transmit to another node. " 

"In one embodiment, the nodes in the list are 4-byte IPv4 unicast addresses, thus the left 
and right parentheses can be encoded in a single byte using values that are not used as the 
first byte of an IPv4 unicast address. In other words, a left parenthesis might be a byte 
with a decimal value of 224, for example, and a right parenthesis might have a value of 
225. Also there are various ways to indicate the length of the field comprising the 
multicast routing information. One way is to include a length field in the packet." 

U.S. Patent No. 6,625,773 col. 4, lines 2-16, which states 

"The new packet type, which can be called "small group multicast" packet, is a level 3 
packet which is to say that it is at the same level as IP in the protocol stack. In fact it has 
much the same function as an IP packet, except for the fact that it is addressed to a list of 
destinations as opposed to a single destination. Ignoring some details, the packet that A 
sends to Rl might look like this: Level 2 header: <dest=level 2 address of Rl> <src=level 

2 address of A> <protocol=small group multicast (i.e. a new level 3 packet type). Level 

3 header: <dest=B C D> <src=A> followed by the payload that A wants delivered to B, C 
and D." 
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The claim element "wherein at least one of the plurality of destination network 
addresses is a unicast address/' is supported in: 

U.S. Patent No. 6,415,312 col. 3, lines 48-49; U.S. Patent No. 6,502,140 col. 3, lines 47- 
48, which states 

"In one embodiment, the nodes in the list are 4-byte IPv4 unicast addresses" 

The claim element "and wherein the mail message is destined for reception at the 

destination corresponding to the unicast address as an ordinary unicast packet" is 

supported in: 

U.S. Patent No. 6,415,312 col. 3, lines 48-49; U.S. Patent No. 6,502,140 col. 3, lines 47- 
. 48, which states 

"In one embodiment, the nodes in the list are 4-byte IPv4 unicast addresses" 
U.S. Patent No. 6,502,140 col. 2, lines 23-25, which states 

"The scheme has the added benefit that packets always take the "right" path; that is, the 
path determined by the ordinary unicast route protocols" 

U.S. Patent No. 6,502,140 col. 6, lines 7-26, which states 

"(3) The routers do not have to run a multicast routing protocol for these multicast 
groups. They do not have to send, receive, or process any multicast routing protocol 
messages and the routers do not have to store any per flow state for each of the 
potentially large number of multicast flows that may be present in the network." 

(4) Traffic follows the correct paths as determined by the unicast routing protocols and 
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the traffic is not concentrated in a small portion of the network. Network efficiency and 
latency is optimized. 

(5) There is no need to talk to a single, centralized entity to acquire a unique multicast 
address when you set up a multipoint conference, which is important since such an entity 
can be a bottleneck and a point of failure. 

(6) A majority of the forwarding that takes place in one of these multicast trees is 
conventional unicast forwarding, a highly optimized path in modern routers which runs 
very fast. The slower multicast forwarding only occurs at the "forks" in the tree, which 
also increases the performance and scalability of this scheme." 

U.S. Patent No. 6,625,773 col. 4, lines 47-60, which states 

"When the packet reaches R7, R7 will send a packet on to R8, with a destination list of 
<C>, and a packet on to R9 with a destination list of <D>. (The packets sent to R8 and 
R9 could be "small group multicast" packets with a single address in the destination list 
or they could be ordinary unicast packets addressed to C & D respectively.) R8 and R9 
will then forward appropriate packets on to C and D respectively." 

"One advantage of using an ordinary unicast for the last hop is that this allows hosts with 
"standard" TCP/IP stacks to receive the new multicast transmissions in a way. that does 
not require any modifications in the host TCP/IP stacks. (If a source sends packets to a 
multicast "exploder," source nodes can also use "standard" TCP/IP stacks)." 

With respect to Claim 2 and similarly for Claims 4 and 7, the following claim chart is 
provided, which identifies adequate for each claim element of Claim 2 in one or more of 
the following U.S. Patent Nos. 6,415,312, 6,502,140, 6,625,773. 



wherein the reliable multicast technique 
comprises a reliable Small Group Multicast 



U.S. Patent No. 6,415,312 at the Title, col. 
6, lines 54-67 to col. 7, lines 1 to 38. 
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technique 



Each claim element of Claim 2 is supported, for example, in U.S. Patent No. 6,41 5,3 12 at 
the Title, which states "Reliable Multicast For Small Groups" and at col. 6, lines 54-67, 
which states 

"A reliable multicast scheme can be built by extending the multicast scheme for small 
groups as discussed above. This scheme includes all the advantages discussed above and 
it provides reliable multicast transmission. The scheme would work as follows. The EM 
header would include a sequence number and a checksum similar to TCP, which would 
be used to keep track of the bytes that have been sent and the bytes that have been 
successively received by each of the destination nodes. Each of the destinations would 
send acknowledgment signals (e.g, packets), or ACKs, to inform the sender of the bytes 
that they have received successfully and error-free. Two types of acknowledgments may 
be used: positive ACKs indicating an error-free detection at the receiving node and 
negative ACKs indicating that an error was detected in the received packet or packets. 
The checksum could be used to determine if a packet has been received error-free. Other 
error detection or reliability mechanisms can be used (e.g, a cyclic redundancy check). 

As m TCP, the ACK includes a sequence number to indicate the last byte that has been 
successfully received. The sequence number could be that of the last byte successfully 
received or the first byte that has not yet been successfully received. 

Also as in TCP, the sender could conclude that a receiver has not successfully received a 
packet when it does not receive an appropriate ACK within a certain period of time. As in 
TCP, the sender retransmits a packet that has not been successfully received. But unlike 
TCP, which re-transmits a packet to a single receiver, the reliable multicast scheme may 
need to retransmit a packet to more than one receiver. 
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When the sender needs to retransmit a packet, it uses a multicast tree for the 
retransmission. Since the sender knows the receivers that it needs to resend to and since it 
knows the (unicast) route to each of these receivers (as described above), it can build a 
multicast distribution tree and appropriate multicast routing information for the subset of 
receivers that it needs to re-send to. 

Thus the retransmissions arc optimized. Bandwidth is not wasted retransmitting 
information to nodes that have already successfully received that information. (If the 
sender needs to retransmit a packet to a singe receiver, the "multicast distribution tree" 
will, of course, be a "tree" with a single leaf.)(a receiving node can be an ultimate 
destination node or an intermediate node). 

The waiting period for re-transmission can be adjusted such that unnecessary delays are 
not introduced into the system. The waiting period can also be adjusted to the longest 
return time. It is also possible to use a cumulative acknowledgment scheme (as in TCP) 
wherein the source node could use the notion of a transmission window to send a stream 
of packets without waiting for an acknowledgment of each one." 

With respect to Claim 3, which includes similar claim language to Claim I, see the 
corresponding support discussed above regarding Claim 1 . With respect to Claims 5, 11, 
16, and 20, see the corresponding support for Claim 2 discussed above. With respect to 
Claims 8 and 13 see the corresponding support for Claim 1 discussed above and in U.S. 
Patent No. 6,625,773 at the Abstract. With respect to Claim 9, see the corresponding 
support found in U.S. Patent No. 6,625,773 at col. 2, lines 40-56. With respect to Claims 
10, 15, and 19 see the corresponding support found in U.S. Patent No. 6,625,773 at col. 2, 
lines 40-56. With respect to Claims 14 and 18 see the corresponding support discussed 
above for Claim 8. With respect to Claim 17, see the corresponding support discussed 
above regarding Claims 1 and 8. With respect to Claim 12, see the corresponding 
support discussed above regarding Claim 2. 

Page 25 of 47 



PACE 26/48 ' RCVD AT 6/6/2008 3:22:28 PM [Eastern Daylight Time] ' SVR:U8PTO-EFXRF-S/8 ' DN1S:2738300 ' CSID:361 989 9812 ' DURATION (mm-ss): 17-20 



06/06/2086 15:22 561-989-9812 



FLEIT KAIN ET AL. 



PAGE 27/48 



Appl. No. 09/696,566 

AmdL dated 6/06/2006 

Kcply to the Office Action of 03/06/2006 



As can be seen, U.S. Patent Nos. 6,415,312, 6,502,140, 6,625,773 provide clear 
and adequate support for claims 1-20 of the present Application. Therefore, the 
Applicant believes that the rejection under 35 U.S.C. § 112 has been overcome and 
should be withdrawn. 

Furthermore, the present invention now incorporates by reference the entire 
teachings of the U.S. Patent Nos. 6,415,312, 6,502,140, 6,625,773. U.S. Patent No. 
6,626,773, which was filed on June 9, 1999, incorporates by reference the cumulative 
teachings of U.S. Patent Nos. 6,415,312 and 6,502,140. Since U.S. Patent Nos. 
6,415,312, 6,502,140, and 6,625,773 were filed on January 29, 1999, January 29, 1999, 
and June 9, 1999, giving the present application a priority date of at least June 9, 1999, 
which is prior to the filing date of June 9, 2000 for the hnai reference, the Imai reference 
is disqualified as a relevant prior-art reference. 



Double Patenting Rejection 
(2-3) The Examiner rejected Claims 8-20 under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable of some claims of copending 
U.S. Patent Application No. 09/696, 116 in view of Imai et al. U.S. Patent No. 6,862,279. 
The Examiner further states that this is a provisional obviousness-type double patenting 
rejection because the claims of the related application have not yet been patented. 

With respect to Claims 8 and 10, as discussed above, Imai has been removed as a 
relevant prior art reference and therefore, the obviousness-type double patenting rejection 
can no longer stand. However, even so, the Applicant respectfully disagrees with the 
Examiner that Imai teaches that "the multicast packet includes a packet header 
comprising the plurality of destination network address wherein at least one of the 
plurality of destination network address is a unicast address". Please see the following 
remarks and arguments regarding Claim 8 starting on page 38 of this Response. 
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Furthermore, The U.S. Patent Application No. 09/696,1 16 is commonly assigned 
herewith to International Business Machines Corporation of New York, includes the 
same inventor as the present invention, and was filed on the same day, October 25, 2000, 
as the present invention. Although the Applicant believes there is no double patenting 
with the present invention in view of the U.S. Patent Application No. 09/696,116 
application since the present invention is directed towards multicast enabled web content 
distribution and the present invention is directed towards multicast enabled e-mail, the 
Applicant, if required, is not adverse to submitting a terminal disclaimer itfwhen the U.S. 
Patent Application No. 09/696,1 16 is allowed by the Examiner. Accordingly, since Imai 
has been disqualified as a prior art reference and in view of the remarks and arguments 
below, the Examiner is respectfully requested to withdraw the provisional rejection of the 
Claims 8-20 based on obviousness-type double patenting. 



Claims Rejection under 35 U.S.C. SI 03 

(4-5) The Examiner rejected Claims 1, 3, 6, 8, 10, 13-15, and 17-19 under 35 U.S.C. 
§ 103(a), as being unpatentable over Haggerty et al. (U.S. Patent No. 6,331,983) in view 
of Hardjono (U.S. Patent No. 6,643,773), and further in view of Imai et al. (U.S. Patent 
No. 6,862,279). 

The Examiner concluded that Haggerty teaches the present invention as recited 
for Claims 1, 3, 6, 8, 13, and 17, and cited several paragraphs in Haggerty in support 
thereof. Applicant respectfully disagrees with the Examiner. In particular, the Examiner 
repeated his assertions from the previous Office Action that Haggerty teaches the 
following in Claim 1 : 



"receiving a mail message that is created and sent by a user, 
the user associating the mail message with a plurality of 
destinations" 
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The Examiner also repeated the same for the following element of Claims 3 and 
6: 

"a mail message with addresses corresponding to a plurality 
of destinations;" 



The Examiner, once again, relied upon col. 11, line 60 to col. 12, line 15 and col. 
12, line 55 to col. 13, line 12 of Haggerty, to reject the above elements of Claims 1, 3, 
and 6. 

The Applicants respectfully suggest that the Examiner is confusing ordinary 
multicast as taught by Haggerty with the method of the presently claimed invention. 
Haggerty nnlv teach^ standard multiset i n standard multicast, which is receiver 
oriented because the receivers, and not the sender, associate themselves with a multicast 
group address, a multicast packet is sent to a single multicast group address. The sender, 
for example, has no way of selecting which receiver will or will not receive the multicast 
message. The message is sent to all recipients or to none . 

Where the Examiner directs the Applicant to in Haggerty, Haggerty explicitly 
states "to send an IP multicast datagram (packet), the sender specifies the IP multicast 
group address". See Haggerty at col. 3, lines 66-67). The final destinations are not 
specified by the sender, only the multicast group address. Also, note that the sender 
in traditional multicast, which is taught by Haggerty, is not a user. The sender is a 
multicast server device in the network. Also, using traditional multicast, as taught by 
Haggerty, is inappropriate for distributing mail since in traditional multicast the sender 
(e.g., a multicast server device) does not associate any particular destinations with a 
message. 

The previous Response clearly pointed out the differences between Haggerty and 
the presently claimed invention. Applicants have amended claims 1, 3, 6, 8, 13, and 17 to 
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more clearly recite "individual destinations" and "individual network addresses". For 
example, Claim 1 and similarly Claims 3, 6, 8, 13, and 17 now more clearly recite: 

receiving a mail message that is created and sent by a user, the user 
associating the mail message with a plurality of individual destinations; 
and 

sending a single copy of the mail message, in a multicast packet 
and using a reliable multicast technique, across the network via at least 
one intermediate node to the plurality of individual destinations, the 
plurality of individual destinations corresponding to a plurality of 
individual destination network addresses, wherein the multicast packet 
includes a packet header comprising the plurality of individual destination 
network addresses, wherein at least one of the plurality of individual 
destination network addresses is a unicast address, and wherein the mail 
message is destined for reception at the individual destination 
corresponding to the unicast address as an ordinary unicast packet. 

No new matter was added. Support for these amendments may be found in the 
specification as originally filed. See for example, the Specification at page 4, line 21 to 
page 8, line 7; incorporated U.S. Patent No. 6,625,773, column 3, lines 30-67 to column 
4, lines 1-52; col. 5, lines 20-28; and the incorporated U.S. Patent No. 6,415,312, column 
3, lines 1-59. Also, the claim chart included above includes support for these 
amendments. 

According to an embodiment of die presendy claimed invention, on the other 
hand, the sender (i.e., including the user) specifically associates individual destinations, 
by their individual destination addresses, with the mail message created by the sender. 
Therefore, with respect to claim 1, Haggerty does not teach, anticipate or suggest 
"receiving a mail message that is created and sent bv a user , the user associating the mail 
message with a plurality of individual destinations " as recited by the present invention; 
Furthermore, the multicast packet of Haggerty only has a single multicast p r oup address 
and not a plurality of individual destinations, as recited for the presently claimed 
invention. Therefore, the present invention distinguishes over Haggerty for at least these 
reasons as well. 
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The Examiner goes on to state that Haggerty teaches the claim element: 

"sending a single copy of the mail message, in a multicast packet 
and using a reliable multicast technique, across the network via at 
least one intermediate node to the plurality of destinations, the 
plurality of destinations corresponding to a plurality of destination 
network addresses" 



and cites col. 6, lines 12-22; col. 13, lines 36-45; and col. 17, lines 30-64, in support 
thereof. Applicant respectfully disagrees. The Applicant points out to the Examiner that 
a single multicast group address as taught by Haggerty is NOT the same as a plurality 
of destinations that correspond to a plurality of destination network addresses. In 
standard multicast, as taught by Haggerty, receivers subscribe and associate themselves 
with a multicast group address. The Applicant requests clarification from the Examiner 
on how the Examiner is finding a single multicast group address to be the same as a 
plurality of destinations that correspond to a plurality of destination network addresses. 

The multicast packet in Haggerty includes a single multicast group address that 
allows the multicast packet to be transmitted to the multicast group. The single multicast 
group address is not used for sending the multicast packed to local host subscribers. The 
MCast router uses its own information (i.e. its knowledge of each, of its subscribers) to 
forward a copy of the packet onto its local subnet Also, as described above, Haggerty is 
completely inappropriate for distributing mail since in a mail system the sender/user 
specifies the receivers while in traditional multicast, such as in Haggerty, the receivers 
are the ones that individually subscribe to receive a multicast message and the sender 
(e.g., the multicast server) does not control (does not affirmatively associate the message 
with) who will be the specific individual receivers in the plurality of recipients of the 
multicast message. 
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Furthermore, where the Examiner directs the Applicant to in Haggerty in support 
of the Examiner's assertion that Haggerty teaches a reliable multicast technique, 
Haggerty only teaches using a reliable delivery for standard multicast, which the 
Applicant respectfully reminds the Examiner includes a multicast packet with a sinp lp 
multicast group address . Nowhere does Haggerty teach a reliable multicast technique 
for sending a "a single copy of the mail message, in a multicast packet" "across the 
network via at least one intermediate node to the plurality of individual destinations, the 
plurality of destinations corresponding to a plurality of individual destination network 
addresses". Therefore, the presently claimed invention distinguishes over Haggerty for at 
least these reasons as well. 

The Examiner correctly states on page 9 of the present Office Action that 
Haggerty does not teach "distributing electronic mail message across the network using 
multicast technique". The Examiner states the Haggerty suggests "the use of 
multicasting in transmission of messages/packets over the Internet such as transmission 
of corporate messages to employees and video/audio conferencing". However, the 
Applicant respectfully reminds the Examiner that the multicasting taught by Haggerty is 
standard receiver oriented multicastin g where the multicast packet includes a sinpls 
multicast R roup address and not a plurality of individual destinations addresses as 
recited for the presently claimed invention. Therefore, the presently claimed invention 
distinguishes over Haggerty for at least these reasons as well. 

The Examiner goes on further to state that Hardjono discloses that multicasting is 
well-known in the art for transmitting data messages such as email messages to selected 
groups of users across a network like the Internet and relied upon the Abstract and col. 1 , 
lines 13-25 of Hardjono in support thereof. Applicant respectfully disagrees with the 
Examiner and sets below the similar arguments as made in the previous two Responses. 

Hardjono merely mentions in the background section "[o]ne simple example of 
multicasting entails transmitting an Email message to a plurality of users that each are on 
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a mailing list." See Hardjono at col. 1, lines 15-17. Hardjono never again mentions an 
email message nor how to use multicast with an email message. Therefore, Hardjono is 
not enabling with respect to using multicast with an email message. "All the limitations 
of a claim must be considered when weighing the differences between the claimed 
invention and the prior art in determining the obviousness of a process or method claim". 
See MPEP § 2116.01. "To support a rejection under 35U.S.C. 103, the collective 
teachings of the prior art must nave suggested to one of ordinary skill in the art that, at 
the time the invention was made, applicant's claimed invention would have been 
obvious." See Id "Motivation to make or use the nonobvious product must be present in 
the prior art for a 35 U.S.C. 1 03 rejection to be sustained" See Id 

The following comments with respect to Haggerty and Hardjono were included in 
the last Response and are repeated to show the differences between Haggerty/Hardjono 
and the presently claimed invention. As stated above, Hardjono merely mentions 
transmitting an email message using multicasting. Nowhere does Hardjono enable a 
multicast packet for sending a mail message. The collective teachings of Haggerty and 
Hardjono do not suggest to one or ordinary skill in the art that at the time the present 
invention was made it would have been obvious. Additionally, Hardjono is directed 
towards authenticating messages in a multicast system and explicitly states that multicast 
is used to transmit messages to selected groups of users. See for example, Hardjono at 
col. 1, lines 13-15. Additionally, at the time the present invention, one of ordinary skill 
in the art would be familiar with using unicast for transmitting email and not multicast. 
Multicasting email messages was not well known in the art as asserted by the Examiner. 

Hardjono, like Haggerty, teaches standard multicast and therefore the Applicant 
respectful suggests the Examiner is incorrect when stating that "multicasting technique is 
well-known in the art for transmitting data messages such as email messages..." As 
discussed above, traditional multicast is not appropriate for the distribution of electronic 
mail because in traditional multicast it is the receivers individually who subscribe and 
determine they will be receivers in the multicast group. The sender, in traditional 
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multicast being the multicast server and not a user, does not determine the receivers of a 
multicast packet. The sender, on the other hand, in the presently claimed invention does 
affirmatively determine and associate with the multicast packet who are the individual 
recipients of the electronic mail message. The plurality of unicast addresses are user 
specified and associated with the mail message. 

Neither Hardjono, nor the Examiner has pointed out, how a sender in Hardjono 
can send electronic mail to receivers of his/her choice with traditional multicast. 
Contrary to Hardjono's assertion, conventional multicast is not used to transmit an 
electronic mail message to a plurality of users and traditional multicast does not usually 
include provision for reliable transmissions, as has been claimed for the present 
invention. Using multicast for email messages is not well known in the art, but is in fact 
well known not to be used to transmit email messages. 

Therefore, Hardjono fails to teach "receiving a mail message that is created and 
sent by a user, the user associating the mail message with a plurality of destinations; and 
sending a single copy of the mail message, in a multicast packet and using a reliable 
multicast technique, across the network via at least one intermediate node to the plurality 
of destinations, the plurality of destinations corresponding to a plurality of destination 
network addresses. .." as recited for Claims 1, 3, and 6 respectively. Therefore, Claims 1, 
3, and 6, distinguish over Hardjono for at least these reasons. 

Continuing further, when there is no suggestion or teaching in the prior art for that 
disclosed in the application, the suggestion can npj come from the Applicant's own 
specification. As the Federal Circuit has repeatedly warned against using the Applicant's 
disclosure as a blueprint to reconstruct the claimed invention out of isolated teachings of 
the prior art. See MPEP §2143 and Grain Processing Corp. v. American Maize-Products, 
840 F.2d 902, 907, 5 USPQ2d 1 788 1792 (Fed. Cir. 1988) and In re Fitch, 972 F.2d 160, 
12 USPQ2d 1780, 1783-84 (Fed. Cir. 1992). 
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Additionally, the Examiner recites 35 U.S.C. § 103. The Statute expressly 
requires that obviousness or non-obviousness be determined for the claimed subject 
matter as a whole and the key to proper determination of the differences between the 
prior art and the present invention is giving foil recognition to the invention as a whole. 
Haggerty taken alone and/or in view of Hardjono simply does not teach or suggest 
receiving a mail message that is created and sent by a user, the user associating the mail 
message with a plurality of individual destinations, as recited for Claim 1; a mail 
message with a plurality of individual addresses (not a single group address) 
corresponding to a plurality of individual destinations, as recited for Claims 3 and 6; or 
sending a single copy of the mail message, in a multicast packet and using a reliable 
multicast technique, across the network via at least one intermediate node to the plurality 
of individual destinations, the plurality of individual destinations corresponding to a 
plurality of destination network indiyjdjial addresses, .... as recited for Claims 1, 3 and 
6. Therefore, Claims 1, 3, and 6, distinguish over Haggerty alone and/or in view of 
Hardjono for at least these reasons. 

The Examiner further states on page 10 of the present Office Action that Haggerty 
does suggest the use of multicasting technique with unicast packets and cites col. 3, tine 
51, to col. 4, line 31, in support thereof. However, the Applicant respectfully disagrees. 
The Applicant respectfully reminds the Examiner that Haggerty teaches standard 
multicast which uses a multicast packet w ith a single multicast groiin a ri<W« Col. 
3, line 51 to col. 4, line 31 merely teaches how standard multicast with a single multicast 
group address works. The plurality of unicast address in the presently claimed invention 
are user specified and associated with the email. The Applicant is unsure of how the 
Examiner is concluding that multicast packet with a single multicast group address is the 
same as a multicast packet including a plurality of destinations corresponding to a 
plurality of destination network addresses where at least one destination network address 
is a unicast address. 
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The Applicant is especially unsure of how the Examiner can make the above 
conclusion when Haggerty explicitly defines that the type of address in a multicast packet 
is multicast group address. For example, Haggerty teaches a standard multicast which 
uses a Class D IP address. A Class D address is a single address for a mnhi^f 
grouE. See the Examiner's citations at col. 3, line 51 to col. 4, line 31 . In fact, Haggerty 
even explicitly teaches that the multicast packet only contains a single destination TP 
address of a multicast grniin See Examiner's citation of Haggerty at col. 13, lines 10- 
12. Nowhere does Haggerty even suggest using unicast packets with a multicasting 
technique. Haggerty teaches that unicast and multicast are different and that they are 
treated differently. Accordingly, the present invention distinguishes over Haggerty for at 
least these reasons as well. 

The Examiner correctly states on page 10 of the present Office Application that 
"Haggerty does not explicitly teach the multicast packet includes a packet header 
comprising the plurality of destination network address wherein at least one of the 
plurality of destination network addresses is a unicast address and wherein the 
packet/message is destined for reception at the destination corresponding to the unicast 
address as an ordinary unicast packet". However, the Examiner goes on to combine 
Haggerty with Imai to overcome the deficiencies of Haggerty. In particular, the 
Examiner states that Imai "discloses the multicast packet includes a packet header 
comprising the plurality of destination network address wherein at least one of the 
plurality of destination network address is a unicast address". 

As stated above, the Application now claims priority from three prior co-pending 
applications, the latest filed on June 9, 1999. Imai was later filed on June 9, 2000. 
Therefore, the Applicant respectfully submits that Imai is disqualified as a prior art 
reference. However, additional arguments with respect to Imai are given below. 

The Applicant respectfully points out where the Examiner directs the Applicant to 
in Imai is silent on a mail message being "reception at the destination corresponding to 
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the unicast address as an ordinary unicast packet". In fact, nowhere does Imai teach that 
a "mail message is destined for reception at the individual destination corresponding to 
the unicast address as an ordinary unicast packet" . Imai only teaches that a packet, which 
is referring to a multicast packet, is received. See Imai generally. Furthermore, Imai is 
still directed towards a multicasting system where clients subscribe to a multicast group. 
For example, col. 3, lines 41-42 state that "one's participation is kept secret to other 
clients participating in the multicast". Col. 15, lines 6-10 state "the sender can search the 
route topology, and arrange the destination information so as to lower the route search 
cost at the router" and "the client can join or leave the multicast group without any 
action. . This clearly shows that Imai is teaching multicast wherein users subscribe to a 
multicast group. Therefore, packets are received by clients as a multicast packet and not 
as a unicast packet. 

In contrast, Claims 1, 3, and 6, recite "receiving a mail message that is associated 
with a plurality of individual destinations; and sending a single copy of the mail 
message, in a multicast packet and using a reliable multicast technique, across the 
network via at least one intermediate node to the plurality of individual destinations, the 
plurality of individual destinations co rresponding to a plurality of Individual destination 
network addresses, wherein the multicast packet includes a packet header comprising the 
plurality of individual destination netw o rk addresses , wherein at least one of the p lurality 
of individual destination network a d dresses is a unicast address, and wherein the mail 
message is destined for reception at the individual destination corresponding to the 
unicast address as an ordinary unicast p acket" 

Nowhere does Haggerty alone or in combination with Imai teach or suggest the 
above claim elements recited for amended Claims 1, 3, and 6. Haggerty clearly teaches 
conventional multicasting using a conventional multicast packet. Haggerty alone or in 
any arguable combination with Imai does not teach "wherein the mail message is 
individual destined for reception at the individual destination corresponding to the unicast 
address as an ordinary unicast packet " and "sending a single copy of the mail message, in 
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a. multicast packet using a reliable multicast technique, across the network via ... to the 
plurality of individual destinations, the plurality of individual destinations corresponding 
to a plurality of individual destination network addresses ..." Conventional multicast as 
taught by Haggerty, and multicasting as taught by Imai, is used for transmitting a large 
amount of data to multiple destinations that subscribe to the multicast server. This is 
different than the transmitting of an electronic mail message, as recited for Claims 1, 3, 
and 6. Furthermore, nowhere does Haggerty alone or in combination with Imai teach a 
reliable multicast technique for sending a multicast packet including a mail message. 
Imai is completely silent on a reliable multicast technique. Nowhere does Haggerty teach 
using a reliable multicast technique ''wherein the multicast packet includes a packet 
header comprising the plurality of network individual destination addresses, wherein at 
least one of the pluralities of network individual destination addresses is a unicast 
address". Accordingly, the presently, claimed invention distinguishes over Haggerty 
alone and/or in combination with Imai for at least these reasons. 

Continuing further, when there is no suggestion or teaching in the prior art for 
"receiving a mail message that is created and sent by a user, the user associating the mail 
message with a plurality of individual destinations; and sending a single copy of the mail 
message, in a multicast packet and using a reliable multicast technique, across the 
network via at least one intermediate node to the plurality of individual destinations, the 
plurality of individual destinations corresponding to a plurality of individual destination 
network addresses usi ng a reliable multicast technique , wherein the multicast packet 
includes a packet hea der comprising the plurality of individual destination network 
addresses, wherein at least one of the plurality of individual destination network 
addresses is a unica st address, and wherein the mail message is destined for reception at 
the individual destination corresponding to the unicast address as an ordinary unicast 
packet", the suggestion can not come from the Applicant's own specification. As the 
Federal Circuit has repeatedly warned against using the Applicant's disclosure as a 
blueprint to reconstruct the claimed invention out of isolated teachings of the prior art. 
See MPEP §2143 and Grain Processing Corp. v. American Maize-Products, 840 F.2d 
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902, 907, 5 USPQ2d 1788 1792 (Fed. Cir. 1988) and In re Fitch, 972 F.2d 160, 12 
USPQ2d 1780, 1783-84 (Fed. Cir. 1992). 

Moreover, the Federal Circuit has consistently held that when a § 103 rejection is 
based upon a modification of a reference that destroys the intent, purpose or function of 
the invention disclosed in the reference, such a proposed modification is not proper and 
the prima facie case of obviousness cannot be properly made. See In re Gordon, 733 
F.2d 900, 221 USPQ 1 125 (Fed. Cir. 1984). 

Here the intent, purpose, and function of Haggerty taken alone or in view of Imai 
is multicasting using a standard multicasting packet, where the multicast packet includes 
a single multicast group address. Because Imai explicitly teaches that multicast route 
information is not used, that is, multicast distribution is realized by the unicast route 
information only and the Examiner states the Imai includes unicast addresses within the 
packet header, this combination as suggested by the Examiner destroys the intent and 
purpose of Haggerty's intent of standard multicasting, which uses multicast route 
information and includes a single mul t icast group address In contrast, the intent of the 
present invention is using a multicast packet to deliver an email message to a plurality of 
individual destinations as an ordinary unicast packet. Accordingly, the combination of 
Haggerty and Imai results in an inoperable system. Therefore, the Examiner's case of 
"Prima Facie Obviousness " should be withdrawn. 

Furthermore, the Federal Circuit stated in McGinlev v. Franklin Sports, (Fed 
Cir 2001) that if references taken in combination would produce a "seemingly inoperative 
device," such references teach away from the combination and thus cannot serve as 
predicates for a prima facie case of obviousness. In re Sponnoble . 405 F.2d 578, 587, 
160 USPQ 237, 244 (CCPA 1969) (references teach away from combination if 
combination produces seemingly inoperative device); see also In re Gordon. 733 F.2d 
900, 902, 221 USPQ 1125, 1127 (Fed. Cir. 1984) (inoperable modification teaches 
away). Here, Haggerty teaches multicasting using a standard multicasting packet and 
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Imai teaches an incompatible system where multicast route information is not used. 
Therefore, the combination of Haggerty with Imai to produce the presently claimed 
invention where a multicast packet is used to deliver an email message to a plurality of 
destinations as an ordinary unicast packet would produce an inoperable device. 
Accordingly, the combination of Haggerty and Imai is improper. 

Therefore, Haggerty alone and/or in combination with Hardjono and/or in 
combination with Imai does not teach, anticipate, or suggest the present claimed 
invention. Applicant believes that the rejection of Claims 1, 3, and 6 under 35 U.S.C. § 
103(a) has been overcome. Applicant requests that the Examiner withdraw the rejection 
and allow Claims 1,3, and 6, 

Regarding Claims 8, 13, and 17, the Examiner concluded that Haggerty teaches 
the present invention as recited for Claims 8, 13, and 17 and cited several paragraphs in 
Haggerty in support thereof. Applicant respectfully disagrees with the Examiner. In 
particular, the Examiner concluded that Haggerty teaches the following in Claims 8, 13, 
andl7: 

"receiving a mail message in a multicast packet including a 
plurality of destination network addresses" 

As discussed above, claims 8, 13, and 17 have been amended to more clearly 
recite "...a plurality of individual destination network addresses". Also, as discussed 
above, Haggerty does not teach "receiving a mail message in a multicast packet including 
a plurality of individual destination network addresses", Haggerty teaches a single 
multicast group address, which is not a destination network address. Accordingly, the 
arguments above with respect to Claims 1, 3, and 6 are applicable here and will not be 
repeated. 
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The Examiner also concluded that Haggerty teaches the following in Claims 8, 
13, and 17: 

"determining one or more 'next hops' 
corresponding to the plurality of destination 
network addresses in the packet header for 
forwarding the packet" 

The Examiner relied upon col. 12, line 55 to col. 13, line 9 of Haggerty, to reject 
the above step. 

Applicant respectfully disagrees with the Examiner's conclusion that Haggerty 
teaches the above step of the present invention and highlights the arguments made in the 
previous two responses. Haggerty merely discloses a prior art LAN packet, IP packet, 
and IP Multicast packet Twhich only co ntains a sinp l e address for a multicast p rnnp) In 
other words, a multicast packet with a single multicast group address is sent to a router. 
The router receives no other address information and therefore, has to use its own internal 
knowledge of its local hosts to determine where to send a copy of the packet. See 
Haggerty at col. 11, lines 60-67. In other words, Haggerty does not teach including 
individual destination network addresses within a multicast packet header and using these 
individual destination network addresses to forward the packet. Accordingly, Claims 8, 
1 3, and 1 7, distinguish over Haggerty for at least this reason. 

With respect to the remaining assertions made by the Examiner, the above 
arguments and comments made in support of Claims 1, 3, and 6 are likewise applicable 
here and will not be repeated. 

Additionally, Claims 10, 14-15, 18-19, depend from Claims 8, 13, and 17, 
respectively, and, since dependent claims recite all of the limitations of the independent 
claim; it is believed that, therefore, Claims 1.0, 14-15, 18-19 also recite in allowable form. 
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Therefore, in view of the foregoing remarks, Applicant believes that the rejection 
of Claims 8, 10, 13-15, and 17-19 under 35 U.S.C. § 103(a) has been overcome. 
Applicant requests that the Examiner withdraw the rejection and allow Claims 8, 10, 13- 
15,17-19. 

(6) Turning now to Claims 2, 4, 7, 9, and 12, the Examiner rejected these claims 
under 35 U.S.C. § 103(a), as being unpatentable over Haggerty et al. (U.S. Patent No. 
6,33 1 ,983) in view of Hardjono (U.S. Patent No. 6,643,773), and further in view of Imai 
et al. (U.S. Patent No. 6,862,279), and further in view of Boivie et al., "Small Group 
Multicast: A New Solution for Multicasting on the Internet", IEEE, May-June 2000. 

Regarding Claims 2, 4, 7, 9, and 12, the Examiner correctly concluded that 
Haggerty, Hardjono, and Imai do not explicitly teach using Small Group Multicast, as 
recited by Claims 2, 4, 7, 9, and 12. However, the Examiner repeated the argument of the 
previous Office Action and stated that Haggerty does suggest the use of IGMP for 
managing requests to join a multicast group(s) and receive multicast traffic. The 
Examiner cited Haggerty at col. 3, lines 21-29 and col. 4, lines 56-61 in support thereof. 
The Examiner also stated that the Boivie et al. reference discloses the use of multicasting 
data transmissions with a SGM scheme and cited page 75, third column and page 78 of 
the Boivie et al. reference in support thereof. The Examiner, therefore, concluded that it 
would have been obvious to one of ordinary skill in the art at the time the invention was 
made to incorporate small group multicast, as disclosed by SGM, into the transmission of 
multicast messages/packets across the network of information processing units and 
intermediate nodes, as disclosed by Haggerty. 

Applicant respectfully disagrees with the Examiner. Claims 1, 3, and 6, and 
accordingly dependent Claims 2, 4, and 7, which depend from Claims 1, 3, and 6, 
respectively, recite "wherein the mail message is destined for reception at the individual 
destination corresponding to the un icast address as an ordinary unicast packet " Claims 9 
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and 12 depend from Claim 8 and therefore, also recite the novel aspects of the present 
invention as recited for Claim 8. 

As has already been discussed above with respect to the rejection of Claims 1, 3, 
and 6 and 8, 13, and 17, based on the teachings of Haggerty in view of Hardjono and in 
further view of Imai, neither cited reference nor any combination thereof teaches, 
anticipates, or suggests, the presently claimed mail message in a multicast packet 
including a packet header comprising a plurality of individual destination network 
addresses ; at least one of the individual destination network addresses of the plurality of 
individual destination network addresses being a unicast address : or wherein the mail 
message is destined for reception at the individual destination corresponding to the 
unicast address as an ordinary unicast packet . Note that Haggerty explicitly teaches that 
the multicast packet is comprised of a single multicast eroun address Haggerty and 
Hardjono also do not teach using a reliable multicast technique in which a multicast 
packet includes a plurality of destination network addresses, e.g., physical addresses. 
Imai explicitly teaches that multicast route information is not used and makes no mention 
of using multicasting techniques with mail messages. Imai further does not teach that a 
"mail message is destined for receptio n at the individual destination corresponding to the 
unicast address as an ordinary unicast p arW and is directed to multicasting where 
clients subscribe to multicast groups. 

Additionally, the Examiner's reliance on Haggerty suggesting IGMP is misplaced 
for the following reasons given in the previous two Responses: IGMP is used by 
multicast routers to learn the existing host group members on their directly attached 
subnets. See Haggerty at col. 4, lines 57-59. IGMP uses a sjngjemulticast group address 
and therefore, precludes using Small Group Multicast, which uses a plurality of 
destination network addresses, i.e. unicast addresses. 

Applicant also repeats the following arguments from the previous two Responses. 
The Boivie et al. reference, does not teach how to implement a reliable multicast 
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technique based on Small Group Multicast. The Boivie et al. reference merely states that 
it is possible to adapt SGM to support reliable multicast, the reference is not enabling 
with respect to this statement. Also, the Boivie et al. reference does not address mail 
messages, but instead specifically discusses IP multicasting and SGM where users can 
join multicast groups. Nowhere does the reference teach, anticipate, or suggest, using 
multicast for an electronic mail system, especially as recited for the presently claimed 
invention. Note that in the present invention, the sender is determining who the 
individual receivers will be. This is different than traditional IP multicast because in 
traditional IP multicast the receivers actively seek out the information to be received by 
subscribing to a multicast group. The sender of the information does not identify the 
receivers, only a specific multicast group to all non-specific receivers who subscribe to 
the gorup. 

Furthermore, the Examiner recites 35 U.S.C. § 103. The Statute expressly 
requires that obviousness or non-obviousness be determined for the claimed subject 
matter as a whole and the key to proper determination of the differences between the 
prior art and the present invention is giving full recognition to the invention as a whole. 
Haggerty taken alone and/or in view of Hardjono and/or in view of Imai and/or in view of 
Boivie et al. simply does not teach or suggest using Small Group Multicast as recited for 
the presently claimed invention. 

Therefore, in view of the foregoing remarks, Applicant believes that the rejection 
of Claims 2, 4, 7, 9, and 12, under 35 U.S.C. § 103(a) has been overcome. Applicant 
requests that the Examiner withdraw the rejection and allow Claims 2, 4, 7, 9, and 12. 

(7) The Examiner rejected Claims 5, 11, 16, and 20 under 35 U.S.C. §103 (a), as 
being unpatentable over Haggerty et al. (U.S. Patent No. 6,33 1 ,983) in view of Hardjono 
(U.S. Patent No. 6,643,773), and in further view of Imai et al. (U.S. Patent No. 
6,862,279), and in further view of Provino et al. (U.S. Patent No. 6,269,085). 
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Regarding Claims 5, 11, 16, and 20, the Examiner correctly concluded that 
Haggerty, Hardjono, and lmai do hot explicitly teach processing ACKs/NAKs and packet 
retransmissions, as recited for Claims 5, 1 1, 16, arid 20. The Examiner also stated that 
Hardjono suggests the use of acknowledgements received from neighbor nodes and that 
Provino discloses multicast transmission with ACKs/NAKs and retransmission of data 
packets. The Examiner concluded that therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to incorporate ACKs/ NAKS 
and performing packet retransmissions, as disclosed by Provino, into the transmission of 
multicast messages/packets across the network of information processing units and 
intermediate nodes, as disclosed by Haggerty. 

Claims 5, 11, 16, and 20 depend from Claims 3, 8, 13, and 17 respectively. As 
discussed above, neither Haggerty, Hardjono, lmai, nor any combination thereof, teaches, 
anticipates, or suggests, the presently claimed mail message in a multicast packet 
including a packet header comprising a plurality of destination network addresses... 
wherein the mail message is dest ined for reception at the individual destination 
corresponding to the unicast address as an ordinary unicast p acket as recited for Claim 3 
and similarly for Claims 8, 13, and 17. Note that Haggerty explicitly teaches that the 
multicast packet is comprised of a single multicast group address and that lmai teaches 
that multicast routing information is not used and does not teach ' therein the tnq it 
message is destined for reception at the individual destination corresponding to the 
unicast address as an ordinary unicast packet ". Haggerty and Hardjono also do not teach 
using a reliable multicast technique in which a multicast packet includes a plurality of 
destination network addresses, i.e. unicast addresses (See Claim 3, 6, 8, 1 3, and 1 7). 

With respect to Provino, the Examiner relied upon col. 1, lines 10-21, and col. 2, 
lines 5-1 1, to reject Claims. 5, 1 1, 16, and 20. The Examiner's reliance upon the citations 
of Provino is misplaced for the following reasons as stated in the previous two 
Responses. Provino merely discloses standard multicast (multicast packet with a single 
multicast group address). There is no mention in any of the relied upon citations of 
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Provino of "a multicast packet including a packet header comprising a plurality of 
destination network addresses" and therein the mail message is destined for reception 
at the individual destination corresponding to the unicast address as an ordinary unicast 
Eacket", as recited for independent Claims 3, 8, 13, and 17, which Claims 5, 1 1, 16, and 
20 depend from respectively. Provino teaches a multicast packet with a single multicast 
group address and not a plurality of destination network address wherein at least one 
destination network address is a unicast address, as recited for Claims 3, 8, 13, and 17 
and accordingly Claims 5, 1 1, 1 6, and 20. 

Additionally, nowhere does Provino teach determining next hops for an individual 
destination network address of the plurality of individual destination network addresses 
in the packet header, as recited for Claims 8, 13, and 17 and accordingly Claims 11,16, 
and 20. Therefore, Claims 3, 8, 13, and 17 and accordingly Claims 5, 11, 16, and 20 
distinguish over Provino for at least these reasons. 

Therefore, in view of the foregoing remarks, Applicant believes that the rejection 
of Claims 5, 11, 16, and 20 under 35 U.S.C. § 103(a) has been overcome. Applicant 
requests that the Examiner withdraw the rejection and allow Claims 5, 11, 16, and 20. 



Other References Cited 

Applicant has reviewed U.S. Patent No. 6,457,059 and U.S. Patent No. 5,331 ,637 
and believes that the references taken alone or in combination with the references cited 
above do not teach, anticipate, or suggest, the presently claimed invention. 
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Conclusion 

The foregoing is submitted as a full and complete response lo the Official Action 
mailed March 6, 2006, and it is suggested that Claims 1-20 are in condition for 
allowance. Reconsideration of the rejection is requested. Allowance of Claims 1-20 is 
earnestly solicited. 

No amendment made was related to the statutory requirements of patentability 
unless expressly stated herein. No amendment made was for the purpose of narrowing 
the scope of any claim, unless Applicant has argued herein that such amendment was 
made to distinguish over a particular reference or combination of references. 

Applicant acknowledges the continuing duty of candor and good faith to disclose 
information known to be material to the examination of this application. In accordance 
with 37 CFR § 1.56, all such information is dutifully made of record. The foreseeable 
equivalents of any territory surrendered by amendment are limited to the territory taught 
by the information of record. No other territory afforded by the doctrine of equivalents is 
knowingly surrendered and everything else is unforeseeable at the time of this Response 
by the Applicant and his attorneys. 

The present application, after entry of this Response, comprises twenty (20) 
claims, including six (6) independent claims. Applicant has previously paid for twenty 
(20) claims including six (6) independent claims. Applicant, therefore, believes that an 
additional fee for claims amendment is currently not due. 

If the Examiner believes that there are any informalities that can be 
corrected by Examiner's amendment, or that in any way it would help expedite the 
prosecution of the patent application, a telephone call to the undersigned at (561) 
989-981 1 is respectfully solicited. 
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The Commissioner is hereby authorized to charge any fees that may be required 
or credit any overpayment to Deposit Account 50-051 0. 



of the preceding discussion, it is submitted that the claims are in condition 



for allowance. Reconsideration and re-examination is requested. 



FLEIT, KAIN, GIBBONS, GUTMAN 
BONGINI & BIANCO P L. 
55 1 N. W. 77th Street, Suite 1 1 1 
Boca Raton, FL 33487 
Tel (561) 989-9811 
Fax (561)989-9812 
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